home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 968 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.9 KB

  1. From: ajay@lehman.com (Ajay Kamdar)
  2. Message-ID: <4k0m72$gm1@jabba.lehman.com>
  3. X-Original-Date: 4 Apr 1996 09:26:42 -0500
  4. Path: in2.uu.net!bounce-back
  5. Date: 05 Apr 96 03:12:56 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: sample auto_ptr template
  9. Organization: Lehman Brothers, Inc.
  10. References: <009A04DA6A831C40.49800EAC@ittpub.nl>
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMWSPzOEDnX0m9pzZAQGZxQGAiHWUYQ8OjLwHziP2ju2GECoHrcnyPURk
  13.     ntQQ2EnvjswFhHxuWkQ6gMEu7CH4kfpX
  14.     =JZT+
  15.  
  16. In article <009A04DA6A831C40.49800EAC@ittpub.nl>,
  17. Wil Evers <wil@ittpub.nl> wrote:
  18. >Hi,
  19. >
  20. >In article <gregorDp23ts.Axt@netcom.com> gregor@netcom.com (Greg Colvin)
  21. >writes:
  22. >
  23. >> In Santa Cruz we decided to change the auto_ptr copy semantics to
  24. >> allow returns of auto_ptr from functions.  Following is a simple
  25. >> implementation.  
  26. >
  27. >This is a terrible state of affairs, especially when we realize
  28. >auto_ptr is the *only* smart pointer we have in the standard library.
  29. >In my opinion, it should be renamed to zombie_ptr if it is to keep its
  30. >new semantics.
  31.  
  32. I am afraid I agree that this is not going in the right direction.
  33.  
  34. In a post back in February, Greg Colvin provided the history
  35. and motivation behind the auto_ptr proposal. To reiterate
  36. what he said then, the auto_ptr tries to support the following
  37. idioms:
  38.  
  39.   1. "Resource acquisition is intialization".
  40.  
  41.      This idiom is intended to very considerably simplify the
  42.      exception safety of code which allocates some resource,
  43.      operates upon this resource, invokes other functions 
  44.      which could potentially throw an exception, and then
  45.      cleans up the resouce before exiting.
  46.  
  47.      This idiom can be supported cleanly and elegantly by
  48.      the auto_ptr template, without any change to the
  49.      language or the other issues which are causing quite
  50.      a discussion.
  51.  
  52.      This idiom was the *only* idiom which auto_ptr was
  53.      intended to originally support.
  54.  
  55.  
  56.   2. Transfer of resource ownership.
  57.  
  58.      This idiom can be used two ways:
  59.  
  60.      2a. The "sink" is called with a resource acquired by
  61.      the the caller, and the sink is responsible for
  62.      deleting the resource.
  63.  
  64.      2b. The "source" (the caller) is returned a resource
  65.      acquired by the callee, and the caller is responsible
  66.      for deleting the resource.
  67.  
  68.      This idiom requires the auto_ptr to have copy semantics,
  69.      and is the source of all the debate. This idiom was *not*
  70.      the original intent of auto_ptr, and was added in response
  71.      to some experiences reported by Taligent.
  72.  
  73.  
  74. Given this background, it is obvious that trying to support
  75. the Taligent idiom is requiring considerable work, and
  76. it is not clear that a clean solution exists. Greg and others
  77. have tried admirably to come up with solutions, but the extensive
  78. discussions in this newsgroup make it obvious that each of
  79. the solutions leaves many things to be desired. Irrespecitve
  80. of what the Taligent experience has been with this idiom,
  81. the collective experience of the people who have participated
  82. in these discussions (a sum total that far exceeds whatever
  83. Taligent can muster) clearly indicates that the form required
  84. to support the Taligent idiom leaves a lot to be desired.
  85.  
  86. So why not forget about trying to support the Taligent idiom
  87. in auto_ptr and stay with the original intent of providing a
  88. standardized idiom for exception safety? There is no reason
  89. why the two separate idioms should be married together in
  90. one class. What ever happened to the concept of using the
  91. right tool for the right job? It is perfectly ok
  92. for Taligent to impose a particular idiom on Taligent users
  93. -- the users of the Taligent framework have a choice whether
  94. to use the framework or not. But it is another matter to stuff
  95. a questionable form of the idiom down the throats of every C++
  96. user by making it a part of the standard auto_ptr.
  97.  
  98. IMHO, it would be a grave mistake for the standardization
  99. comittee to agree upon an auto_ptr which tries to support
  100. the Taligent idiom. Here's what I suggest:
  101.  
  102.    + The standard auto_ptr should address only the
  103.      "resource acquisition is initialization" idiom. It should
  104.      not try have any copy semantics.
  105.  
  106.    + The supporters of the Taligent idiom can, if they feel
  107.      strongly about it, propose a taligent_ptr class which
  108.      addresses the transfer of resource ownership idiom.
  109.      Programmers can then decide whether to use it or not
  110.      on its own merit independently of any thing else.
  111.  
  112. -- 
  113. Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
  114. Lehman Brothers    |    Phone: (201) 524-5048     |
  115. ---
  116. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  117. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  118. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  119. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  120. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  121.